home *** CD-ROM | disk | FTP | other *** search
/ CD Concept 6 / CD Concept 06.iso / mac / UTILITAIRE / RLaB / PROBLEMS < prev    next >
Text File  |  1995-01-14  |  6KB  |  163 lines
  1.  
  2.     Solutions to some problems.
  3.  
  4.     1.q) When I run `make Test' I get the message:
  5.  
  6.         ***complex division inaccuracy, check manually***
  7.  
  8.     1.a) Some compilers do not generate the best code for complex
  9.     division. Most do. Some will pass or fail the test depending
  10.     upon the level of optimization used. If RLaB fails this test
  11.     do a manual check of complex division to verify that the
  12.     answer is correct to within +/- machine-epsilon. If the answer
  13.     is correct to within +/- machine-epsilon then it is safe to
  14.     use RLaB.
  15.  
  16.     2.q) I get undefined symbols (like pow_zi) when the Makefile
  17.     tries to link rlab?
  18.  
  19.     2.a) Undefined symbols like pow_zi are usually from the f2c
  20.     libraries. If the Makefile found libF77.a and libI77.a, and
  21.     these symbols are still undefined, then you probably have a
  22.     Fortran compiler installed on your machine. Some vendors
  23.     Fortran libraries will work OK. But, other vendors have
  24.     gratuitously changed the libraries. 
  25.  
  26.     Try getting the latest version of the f2c libraries
  27.     (research.att.com, or prep.ai.mit.edu). Or, you could write a
  28.     Fortran interface and mail it to me :-)
  29.  
  30.     3.q) alloca is undefined?
  31.  
  32.     3.a) `make ALLOCA=alloca.o'
  33.  
  34.     4.q) When I run `make Test', it fails immediateley.
  35.  
  36.     4.a) The problem may be that your system does not declare
  37.     strtod() in its header files. strtod() is used heavily by the
  38.     scanner, and if it is not declared the compiler will think it
  39.     returns int, which is not right at all. Fix: add
  40.  
  41.         #include <whatever_include_defs_strtod.h>
  42.  
  43.     5.q) When I run `make Test' RLaB reports an error in round()?
  44.  
  45.     5.a) Some platforms (HP for instance) have a rint() function
  46.     in the system library, but it does not work. To fix: go into
  47.     config.h and comment out the two lines:
  48.  
  49.         #define HAVE_RINT 1
  50.         #define HAVE_RINT_DEC 1
  51.  
  52.     Then RLaB will uses its own rint().
  53.     ***NOTE*** configure now checks for broken rint functions, and
  54.     will setup config.h properly.
  55.  
  56.     6.q) I have compiled RLaB on a Sun, using SunOS-4.1.3 and gcc.
  57.     When I try and run RLaB I get an "out of memory" message, and
  58.     some complaints from flex?
  59.  
  60.     6.a) This is a strange one, it does not happen on all Suns,
  61.     but someone discovered that compiling and linking to the GNU
  62.     libmalloc.a curred the problem.
  63.  
  64.     7.q) (borrowed from Plplot FAQ) 3.5 I would like to issue a
  65.     plot command, have the window appear, or be re-painted, and
  66.     allow the user to continue with command line operation of
  67.     RLaB. I would like the user to be able to resize the window at
  68.     any time or cover/un-cover it at any time and have it re-paint
  69.     itself. The way I can get it to work is: the user issues plot
  70.     command, window appears and is resizable, etc... the user must
  71.     use the 3rd mouse button to "release" the window, after that
  72.     control returns to the command line, but the window will no
  73.     longer resize/repaint.
  74.  
  75.     7.a) This is a feature, not a bug :-).
  76.  
  77.     When the plotting package is waiting for the user to advance
  78.     the page, it is actually waiting for any X event.  So events
  79.     like refresh and resize get intercepted and processed.
  80.  
  81.     Also during the normal course of plotting, the X server is
  82.     periodically polled to find out if there are any events that
  83.     need processing, and handles them if so.  I don't do this on
  84.     every graphics instruction because otherwise the overhead is
  85.     too large -- currently on every 20 line draws, every 10
  86.     polyline draws, and on every other call. 
  87.  
  88.     But once the user signals for the page advance, and control is
  89.     returned to the user program, there is no way for the X driver
  90.     to process any events simply because the control is in your
  91.     program, not in the X driver. The single-headedness of your
  92.     process becomes the culprit here.  You can either sit in an
  93.     event loop, or be doing user code specific things, but not
  94.     both.  There is one improvement that could still be made which
  95.     is to provide a plevents() call so you can explicitly force
  96.     all events to be handled, but that's just a bandaid solution
  97.     so I never put it in. 
  98.  
  99.     The real solution is to fork off the rendering into a separate
  100.     process, and this is just what I did with the Tcl/TK driver.
  101.     So, if you select the tk driver, your code can go about its
  102.     merry way while the graphics window can be refreshed, resized,
  103.     zoomed, printed, dumped, or whatever.
  104.  
  105.     It'd also be a worthwhile project to split the X driver up
  106.     similarly, and there has been some interest in doing that (but
  107.     I don't plan to work on it).
  108.  
  109.     8.q) Trying to run `make install' on a DECstation results in
  110.     make and/or shell errors?
  111.  
  112.     8.a) The DECstation has a buggy make, and a horribly old
  113.     version of sh. Doing
  114.  
  115.         gmake SHELL=/bin/sh5 install
  116.  
  117.     Will yield a clean install. Note: gmake is GNU make.
  118.  
  119.     9.q) I installed RLaB with Plplot and when I "interrupt"
  120.     (Ctrl-c) RLaB, it kills the Plplot tk window ?
  121.  
  122.     9.a) Versions of Plplot earlier than (and including) v4p99g
  123.     pass all signals along to the child plserver
  124.     process. Hopefully this will be fixed, or a workaround
  125.     provided in later versions. But, for now you must modify tk.c
  126.     and recompile Plplot. The following patch modifies tk.c so
  127.     that child plserver processes do not get passed SIGINT
  128.     signals. With this patch you can interrupt RLaB without
  129.     killing plserver.
  130.  
  131. *** tk.c~    Fri May 13 22:43:13 1994
  132. --- tk.c    Sat Jul 16 09:08:24 1994
  133. ***************
  134. *** 1052,1057 ****
  135. --- 1052,1066 ----
  136.           abort_session(pls, "Unable to fork server process");
  137.       }
  138.       else if (pid == 0) {
  139. +         int rs;
  140. +         sigset_t set;
  141. +         sigemptyset (&set);
  142. +         sigaddset (&set, SIGINT);
  143. +         if ((rs = sigprocmask (SIG_BLOCK, &set, 0)) == -1)
  144. +         {
  145. +           fprintf(stderr, "tk.c: sigprocmask troubles\n");
  146. +         }
  147. + 
  148.           fprintf(stderr, "Starting up %s\n", plserver_exec);
  149.           if (execv(plserver_exec, argv)) {
  150.           fprintf(stderr, "Unable to exec server process.\n");
  151.  
  152.     10.q&a) On HP and DEC-Alpha computers you may need to compile
  153.     everything in the "traditional" mode (not ANSI), with the
  154.     exception of r_plot.c. This may also be true for IBMs AIX.
  155.  
  156.     11.q) I am having trouble with compiling fpe.c, I gets lots of
  157.     errors I don't understand.
  158.  
  159.     11.a) Apparently configure did not understand your systems
  160.     method of setting up floating point exceptions. You can
  161.     completely disable the function setup_fpe_handling by running
  162.     configure with the `--disable-fpe' option.
  163.